Wireless communication systems are a ubiquitous part of modern life in many areas. A number of different wireless communication protocols have been developed. For example, Long Term Evolution (LTE) is a set of enhancements to the Universal Mobile Telecommunications System (UMTS) that supports high data rates, low latency, low implementation and operating costs, and a seamless connection to legacy wireless communication networks.
As another example, High Speed Packet Access (HSPA) is an extension of wideband CDMA (WCDMA) protocols. HSPA transmits communication data on shared channels, in packets addressed to specific users. HSPA features short Transmission Time Interval (TTI), link adaptation, fast scheduling, fast retransmission and soft-combining, and advanced modulation, resulting in increased data rates, low latency, and increased system capacity.
A limitation common to all wireless communication systems is the limited battery life of mobile terminals, or user equipment (UE). One known method to preserve UE battery life, supported by numerous wireless communication protocols, is Discontinuous Reception (DRX). DRX reduces battery consumption in the UE by allowing the UE to stop monitoring a downlink control channel, such as the Physical Downlink Control Channel (PDCCH). That is, the UE can turn off its receiver during certain time periods. The time periods during which the receiver is turned off are configured by the network. DRX is configured separately—that is, by means of different parameters—for UEs in RRC_IDLE and RRC_CONNECTED mode.
FIG. 1 depicts the basics of DRX. Periodically, the UE has an “on duration,” during which time it monitors the system for traffic. Following the “on duration” is an opportunity for DRX—that is, a period during which the UE may be relieved from monitoring the system for traffic, thus reducing power consumption and conserving battery power. At the end of the DRX Cycle, the process repeats with another “on duration” and another opportunity for DRX.
The DRX Command MAC Control Element is specified in the 3GPP Technical Specification 36.321, “MAC Protocol specification,” the disclosure of which is incorporated herein by reference in its entirety. The DRX Command MAC Control Element can be used to force the UE into DRX sleep mode. If a DRX Command MAC control element is received, both the On Duration Timer and the DRX Inactivity Timer shall be stopped. Furthermore, upon reception of a DRX Command MAC Control Element the DRX Short Cycle Timer shall be started/restarted and the short DRX cycle should be run if configured. The MAC Subheader is depicted in FIG. 2.
An inactivity timer specifies the number of consecutive downlink subframes during which the UE shall monitor the PDCCH after successfully decoding a PDCCH indicating an initial UL or DL user data transmission for this UE.
The DRX Short Cycle Timer parameter specifies the number of consecutive subframes the UE shall follow the short DRX cycle after the DRX Inactivity Timer has expired. FIG. 3 depicts these relationships. If the UE has decoded a PDCCH indicating new transmission during its “on duration,” the inactivity timer will keep the UE from sleeping after sending uplink (UL) data—that is, it will prevent the UE from stopping its monitoring of PDCCH. After the inactivity timer has expired the Short Cycle Timer is started. The Short Cycle Timer allows up to five Short Cycles, during which the UE may again monitor the PDCCH.
The process of delaying packets in a traffic stream to cause the traffic to conform to some defined profile is called rate shaping or traffic shaping. Rate shaping may be applied, for example, to smooth out traffic in time entering a network. In the enhanced NodeB (eNodeB) of LTE, rate shaping is applied to a number of bearers, effectively shaping on an aggregate bitrate.
A known rate shaping algorithm is the so-called token bucket algorithm, described in Annex B of the 3GPP Technical Standard 23.107, “Quality of Service (QoS) concept and architecture,” incorporated herein by reference in its entirety. The basis for this algorithm is an analogy to a bucket of fixed size, into which tokens, representing an allowed data volume, are injected at a constant rage. These tokens accumulate in the bucket, and the maximum allowed number of tokens is defined by the bucket size. The tokens are consumed by the data packets transmitted. Accordingly, if there are at least as many tokens in the bucket as the packet size, then the packet may be transmitted. Conversely, if the packet size is larger than the number of tokens currently in the bucket, the packet is delayed until sufficient tokens accumulate in the bucket. The parameters defining the token bucket are the token rate, r, and the bucket size, b. A token bucket counter (TBC) variable is used to hold the current number of tokens in the bucket. The token rate corresponds to the maximum or guaranteed bit rate and the bucket size corresponds to the bounded burst size. Data is conformant if the data sent in an arbitrary time period, T, does not exceed b+rT.
FIG. 4 depicts a visualization of the conventional token bucket algorithm applied to rate control over several bearers. At most b tokens can be stored in the bucket and the resulting rate, R, is on average the token rate, r.
FIG. 5 depicts the operation of the token bucket algorithm. Initially, the bucket is assumed full, with TBC=b. A first packet, of length l1, is conformant (sufficient tokens are in the bucket), and it is passed to the wireless network for transmission. The bucket fills at a constant rate over the next interval Δt=t2−t1, until a second packet, of length l2, arrives. The second packet is also conformant (it is smaller than the number of tokens in the bucket, or l2<TBC), and the packet is passed by the rate shaper. A third packet arrives, of length l3, when the bucket contains just enough tokens to pass it as well—completely or nearly depleting the bucket (TBC at or near 0). A fourth packet, of length l4, arrives at time t4, before the bucket has been sufficiently replenished with tokens. The fourth packet is delayed by the rate shaper until TBC>=l4, indicated in FIG. 5 as “Packet delay.”